home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Network Supervisor's Toolkit
/
Network Supervisor's Toolkit.iso
/
logins
/
logrun
/
logrun.doc
< prev
Wrap
Text File
|
1996-07-10
|
6KB
|
110 lines
╔══════════════════════════════════════════════════════════════╗
║ LOGRUN ║
╟──────────────────────────────────────────────────────────────╢
║ ║
║ Novell NetWare Login Utility for Menuing ║
║ By Dave Frailey ║
║ ║
╚══════════════════════════════════════════════════════════════╝
INTRODUCTION
───────────────────────────────────────────────────────────────────────────────
A lot of network administrators like to have a menu program run automatically
after a user logs in. The natural place to ensure this happens is in the
system login script. However, what a lot of administrators don't realize is
that the login script is actually executed by the LOGIN program, ON THE REMOTE
COMPUTER, when a user logs in. The LOGIN program requires and allocates about
80k of memory to perform this function. The problem with the system login
script just going out and running your favorite menuing software is that the
LOGIN program has 80k of memory tied up at this point. What's even worse is
if the login script loads a Terminate and Stay Resident (TSR) program which
then permamently "sandwiches" LOGIN.EXE's memory, rendering it useless even
after everything is said and done, because memory is allocated in contiguous
blocks.
Novell's theory on how to have the login script run your menuing software is
to use the EXIT login script command specifying the name of the menu program
to run. What the EXIT command then does is stuff the name of the menu program
into the keyboard queue, assuming that LOGIN.EXE was run from the dos command
prompt so that the name of the menu program would then come out of the keyboard
queue, as if the user had typed it, and the menu program would then run. What
happens however, if the LOGIN program isn't run from the Dos command line?
Well LOGIN.EXE doesn't know any better and goes ahead and stuffs the keyboard
queue, based on the EXIT instruction in the login script, with the name of the
menu program, and control then returns to the shell that ran LOGIN. Well what
if the characters comprising the name of the menu program were also the same
sequence of keys to delete a file?
The only solid way to run a program after Novell's LOGIN.EXE program terminates
is to trap control of the computer at the point where LOGIN.EXE is about to
return control to the previous program, and then run the program you want run.
The answer to this situation is LOGRUN. What LOGRUN does is install itself
temporarily as a TSR, directly above the memory in use by LOGIN. LOGRUN also
chains itself into the MS-Dos Function Request Dispatcher interrupt vector so
it can determine when LOGIN.EXE is about to exit. After LOGRUN is installed,
it sits dormantly, waiting for LOGIN.EXE to exit. In the mean time the login
script can go on and do any number of things, including running other external
programs. When LOGIN.EXE is about to exit, LOGRUN takes control, releasing
all of LOGIN.EXE's memory and closing all of its files. LOGRUN then shifts
itself down to the start of memory from which LOGIN.EXE was running and also
releases the memory it was temporarily using. Then, LOGRUN resizes the block
of memory it is occupying down to just enough to hold LOGRUN's resident code
(less than 100 bytes) and executes the first program specified. When the
first program specified terminates, an optional second program will execute.
Command Syntax:
LOGRUN [/d][path]program.ext [parameters] [|[path]program.ext [parameters]]
A novell login script might look something like this:
#SYS:PUBLIC\LOGRUN sys:public\menu.exe %LOGIN_NAME
- or -
#SYS:PUBLIC\LOGRUN sys:public\menu.exe %LOGIN_NAME | sys:public\logout.exe
In the first example, LOGRUN will invoke Novell's menuing utility, passing it
the user's login name as the name of the menu file to use. In the second
example the same thing happens, but additionally the user is logged out
automatically when the menu utility terminates.
Note that LOGRUN must be told both the filename AND THE EXTENSION of the
program it is supposed to run when LOGIN.EXE terminates. Parameters normally
given to the program would then follow the program's name.
If the /D switch is given (which must be the first parameter encountered),
LOGRUN will not load and stay resident if a copy of dCOM is already loaded.
This allows you to have some users (who use dCOM normally as their front end)
invoke the network menuing macro from a local macro key, but for other users
not using dCOM, load dCOM and invoke your menuing macros from the login script.
Note: A technical anamoly has been encountered on occassion when calling the
Novell LOGOUT.EXE program from LOGRUN without any parameters. LOGOUT
sometimes doesn't parse the command line properly (this may be associated
with an odd behaviour of LOGIN.EXE when it runs a program in that it
passes a null terminated command line instead of a CR terminated like
Dos does). In any event, if you see this behaviour and don't want to
explicitly give a file server name after the LOGOUT.EXE command, using
an asterick will accomplish the same effect of logging out of all file
servers and fix the problem.
For example:
#SYS:PUBLIC\LOGRUN sys:public\menu.exe %LOGIN_NAME | sys:public\logout.exe *
Dave Frailey
September 1990
DAC Micro Systems
40941 176th St E
Lancaster, CA 93535
Voice: 805/264-1700
Data: 805/264-1219